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DETAILED ACTION 

Response to Amendment 

1. Applicant's amendments and accompanying remarks mailed 03/04/201 1 have been 
entered and carefully considered. Claims 16, 17, 19-23,26-28,32-34 and 36 are amended. Claims 
29-31 and 37 are cancelled. New claim 38 is added. As a result, claims 16-28, 32-34, 36 and 38 
are pending. 

Note that applicant's remarks indicate that claims 16-28, 32-34 and 36 are pending. Examiner 
reads this a minor error and claim 38 is examined with the rest of the claims. Applicant is 
respectfully requested to address this error in any following communication. 

Claim Rejections - 35 USC § 103 

2. The following is a quotation of 35 U.S.C. 103(a) which forms the basis for all 
obviousness rejections set forth in this Office action: 

(a) A patent may not be obtained though the invention is not identically disclosed or described as set forth in 
section 102 of this title, if the differences between the subject matter sought to be patented and the prior art are 
such that the subject matter as a whole would have been obvious at the time the invention was made to a person 
having ordinary skill in the art to which said subject matter pertains. Patentability shall not be negatived by the 
manner in which the invention was made. 

3. Claims 16-18, 21-25, 28, 32, 34, and 38 are rejected under 35 U.S.C. 103(a) as being 
unpatentable over Rune et al. (US PGPUB 2004/0167988 Al) (herein after Rune) in view of Jou 
et al. (US PGPUB 2005/0036489 Al) (herein after Jou). 

Regarding claim 16, Rune teaches a method comprising: 
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checking a destination address of a received packet and forwarding the packet to at least 
the first device [see paragraphs 0214 and 0215 where an address filtering function 
(intermediate node) receives and passes (forwards) broadcast/multicast packets 
between the scatternet (first device) and LAN (second device)]. 

However Rune does not explicitly teach comparing the destination address of the packet 
with at least one predetermined multicast and/or broadcast address; preventing, the 
transmission of the packet to a first device in response to the addresses matching; in 
response to the address not matching. However, Jou teaches comparing the destination 
address of the packet with at least one predetermined multicast and/or broadcast address; 
preventing, the transmission of the packet to a first device in response to the addresses 
matching; in response to the address not matching [see paragraph 0029 where a 
wireless transport device (intermediate node) receives a broadcast frame; the 
wireless transport device determines whether or not the Destination Address field is 
the same as the local MAC address (predetermined multicast address) of this device; 
if positive (in response the addresses matching), the wireless transport device drops 
the frame]. It would have been obvious for a person having ordinary skill in the art to 
comparing the destination address of the packet with at least one predetermined multicast 
and/or broadcast address; preventing, the transmission of the packet to a first device in 
response to the addresses matching; in response to the address not matching. This is 
desirable because it allows the system to filter out unnecessary traffic (see paragraph 
0019). 
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Regarding claim 17, Rune teaches a method as claimed in claim 16, wherein the packet 
is received from a second device, and wherein the method further comprises connecting a 
first network comprising the first device to a 

second network comprising the second device, and wherein the first and second networks 
that use different data transmission protocols [see paragraphs 0068 and 0069 and fig. 9 
where a Network Access Point is used for bridging a Bluetooth scatternet and an 
Ethernet LAN (different data transmission protocols)]. 

Regarding claim 18, Rune teaches the method as claimed in claim 16, wherein the 
destination address is an internet protocol address [see paragraph 0210 where a 
broadcast ARP request, encapsulated ARP-route request or ARP route request is 
received at the NAP and where the request contains target IP (Internet Protocol) 
address]. 

Regarding claim 21, Rune teaches a system comprising: a first device; 
a second device; and an intermediate node configured to arrange data transmission 
between the first device and the second device; wherein at least the second device is 
configured to multicast and/or broadcast packets to devices in the system; and wherein, 
the intermediate node is configured to forward the packet to at least the first device [see 
paragraphs 0214 and 0215 where an address filtering function (intermediate node) 
receives and passes (forwards) broadcast/multicast packets between the scatternet 
(first device) and LAN (second device)], 
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However, Rune does not explicitly teach wherein the intermediate node is configured to 
check a destination address of a packet received from the second device, the intermediate 
node is configured to compare the destination address of the packet with at least one 
predetermined multicast and/or broadcast address, and wherein the intermediate node is 
configured to prevent the transmission of the packet to the first device in response to the 
addresses matching; and in response to the addresses not matching. However, Jou 
teaches wherein the intermediate node is configured to check a destination address of a 
packet received from the second device, the intermediate node is configured to compare 
the destination address of the packet with at least one predetermined multicast and/or 
broadcast address, and wherein the intermediate node is configured to prevent the 
transmission of the packet to the first device in response to the addresses matching; and 
in response to the addresses not matching [see paragraph 0029 where a wireless 
transport device (intermediate node) receives a broadcast frame; the wireless 
transport device determines whether or not the Destination Address field is the 
same as the local MAC address (predetermined multicast address) of this device; if 
positive (in response the addresses matching), the wireless transport device drops 
the frame]. It would have been obvious for a person having ordinary skill in the art to 
wherein the intermediate node is configured to check a destination address of a packet 
received from the second device, the intermediate node is configured to compare the 
destination address of the packet with at least one predetermined multicast and/or 
broadcast address, and wherein the intermediate node is configured to prevent the 
transmission of the packet to the first device in response to the addresses matching; and 
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in response to the addresses not matching. This is desirable because it allows the system 
to filter out unnecessary traffic (see paragraph 0019). 

Regarding claim 22, Rune teaches an apparatus comprising: 

a processor configured to check a destination address of a received packet, forward the 
packet to at least the first device [see paragraphs 0214 and 0215 where an address 
filtering function (intermediate node) receives and passes (forwards) 
broadcast/multicast packets between the scatternet (first device) and LAN (second 
device)]. 

However Rune does not explicitly teach comparing the destination address of the packet 
with at least one predetermined multicast and/or broadcast address; preventing, the 
transmission of the packet to a first device in response to the addresses matching; in 
response to the address not matching. However, Jou teaches comparing the destination 
address of the packet with at least one predetermined multicast and/or broadcast address; 
preventing, the transmission of the packet to a first device in response to the addresses 
matching; in response to the address not matching [see paragraph 0029 where a 
wireless transport device (intermediate node) receives a broadcast frame; the 
wireless transport device determines whether or not the Destination Address field is 
the same as the local MAC address (predetermined multicast address) of this device; 
if positive (in response the addresses matching), the wireless transport device drops 
the frame]. It would have been obvious for a person having ordinary skill in the art to 
comparing the destination address of the packet with at least one predetermined multicast 
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and/or broadcast address; preventing, the transmission of the packet to a first device in 
response to the addresses matching; in response to the address not matching. This is 
desirable because it allows the system to filter out unnecessary traffic (see paragraph 
0019). 

Regarding claim 23, Rune teaches the apparatus according to claim 22, wherein the 
packet is received from a second device, and wherein the processor is configured to cause 
the apparatus to connect a first network comprising the first device to a second network 
comprising the second device and the first and second networks use different data 
transmission protocols [see paragraphs 0068 and 0069 and fig. 9 where a Network 
Access Point is used for bridging a Bluetooth scatternet and an Ethernet LAN 
(different data transmission protocols)]. 

Regarding claim 24, Rune teaches the apparatus according to claim 23, wherein the 
processor is configured to cause the apparatus to perform data transmission between an 
IEEE 802-based network to which the second device belongs and a bluetooth network to 
which the first device belongs [see paragraphs 0068 and 0069 and fig. 9 where a 
Network Access Point is used for bridging a Bluetooth scatternet and an Ethernet 
LAN (IEEE 802 based network)]. 

Regarding claim 25, Rune teaches the apparatus according to claim 22, wherein the 
destination address is an internet protocol address [see paragraph 0210 where a 
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broadcast ARP request, encapsulated ARP-route request or ARP route request is 
received at the NAP and where the request contains target IP (Internet Protocol) 
address]. 

Regarding claim 28, Rune teaches the apparatus according to claim 22, wherein the 
processor is configured to check, in addition to the comparison of the destination address 
of the packet with at least one predetermined multicast and/or broadcast address, if the 
packet complies with one or more further message transmission conditions, and the 
processor is configured to allow forwarding of the packet to the first device in response to 
the packet complying with the one or more further message transmission conditions [See 
paragraph 0196 lines 10-21 where packet filtering is based on destination address 
and NAL packet type and based on higher layer protocols (one or more further 
message transmission conditions)]. 

Regarding claim 32, Rune teaches a memory storing a computer program, the computer 

program configured to control a processor to perform the following: 

check a destination address of a received packet; and forwarding the packet to at least the 

first device [see paragraphs 0214 and 0215 where an address filtering function 

(intermediate node) receives and passes (forwards) broadcast/multicast packets 

between the scatternet (first device) and LAN (second device)]. 

However Rune does not explicitly teach comparing the destination address of the packet 

with at least one predetermined multicast and/or broadcast address; preventing, the 
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transmission of the packet to a first device in response to the addresses matching; in 
response to the address not matching. However, Jou teaches comparing the destination 
address of the packet with at least one predetermined multicast and/or broadcast address; 
preventing, the transmission of the packet to a first device in response to the addresses 
matching; in response to the address not matching [see paragraph 0029 where a 
wireless transport device (intermediate node) receives a broadcast frame; the 
wireless transport device determines whether or not the Destination Address field is 
the same as the local MAC address (predetermined multicast address) of this device; 
if positive (in response the addresses matching), the wireless transport device drops 
the frame]. It would have been obvious for a person having ordinary skill in the art to 
comparing the destination address of the packet with at least one predetermined multicast 
and/or broadcast address; preventing, the transmission of the packet to a first device in 
response to the addresses matching; in response to the address not matching. This is 
desirable because it allows the system to filter out unnecessary traffic (see paragraph 
0019). 

Regarding claim 34, Rune teaches a memory according to claim 32, wherein the 
computer program is further configured to control the processor to compare one or more 
properties of the packet to properties specified in predetermined transmission conditions 
to determine whether the packet should be forwarded to the first device [see paragraph 
0210 where a broadcast ARP request, encapsulated ARP-route request or ARP 
route request is received at the NAP and where the request contains target IP 
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address and where the address filtering function contained within the NAP 
determines whether the address corresponds to an address that is stored in the ARP 
cache; and where the packet is passed to the NAP-B (i.e. forwarded to the scatternet 
from the LAN) unless that is not addressed to the NAP itself or the address function 
determines from the address table that the destination node is located on the 
receiving side -i.e. the side from which the broadcast packet is received]. 

Regarding claim 38, Rune teaches the apparatus according to claim 27, wherein the 
processor is configured to cause the apparatus to forward at least broadcast packets 
relating to address acquisition to the first device [see paragraph 0082 where the 
messages can be ARP requests (address acquisition)]. 

4. Claims 19,20,26,27 and 33 rejected under 35 U.S.C. 103(a) as being unpatentable over 
Rune as applied to claims 16-18, 21-25, 28, 32, 34, and 38 above and further in view of Vasisht 
(US 2004/0133689). 

Regarding claim 19, Rune teaches a method as claimed in claim 16 as discussed above. 
However, Rune does not explicitly teach the packet is received from a second device, and 
wherein the first device belongs to a mobile handheld subcommittee domain of a 
universal plug and play system and the second device belongs to a home network version 
1 domain of the universal plug and play system. However, Vasisht teaches using UPnP in 
one of the networks [paragraph 0051 line 24]. It would have been obvious for a person 
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having ordinary skill in the art to utilize UPnP (various versions include MHS and Home 
network version) in one of the networks. UPnP (both the Home network and MHS 
versions) is desirable because it allows devices to connect seamlessly. 

Regarding claim 20, Rune teaches a method as claimed in claim 19 including preventing 
multicast packet to the first device as discussed above. However, Rune does not explicitly 
teach Universal Plug and Play-UPnP. However, Vasisht teaches using UPnP in one of the 
networks [paragraph 0051 line 24]. It would have been obvious for a person having 
ordinary skill in the art to utilize UPnP in one of the networks. UPnP is desirable because 
it allows devices to connect seamlessly. 

Regarding claim 26, Rune teaches the apparatus according to claim 22 as discussed 
above. However, Rune does not explicitly teach the packet is received from a second 
device, and wherein the processor is configured to cause the apparatus to provide data 
transmission between the first device belonging to a mobile handheld subcommittee 
domain of a universal plug and play system and the second device belonging to a home 
network version 1 domain of the universal plug and play system. However, Vasisht 
teaches using UPnP in one of the networks [paragraph 0051 line 24]. It would have 
been obvious for a person having ordinary skill in the art to utilize UPnP (various 
versions include MHS and Home network version) in one of the networks. UPnP (both 
the Home network and MHS versions) is desirable because it allows devices to connect 
seamlessly. 
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Regarding claim 27, Rune teaches the apparatus according to claim 25, wherein the 
processor is configured to prevent transmission of universal plug and play discovery 
multicast message to the first device, and the apparatus is configured to forward at least 
the broadcast messages relating to the address definition to the first device. However, 
Vasisht teaches using UPnP in one of the networks [paragraph 0051 line 24]. It would 
have been obvious for a person having ordinary skill in the art to utilize UPnP (various 
versions include MHS and Home network version) in one of the networks. UPnP (both 
the Home network and MHS versions) is desirable because it allows devices to connect 
seamlessly. 

Regarding claim 33, Rune teaches a memory according to claim 32 as discussed above. 
However, Rune does not explicitly teach the computer program is further configured to 
control the processor to prevent transmission of universal plug and play discovery 
multicast packets to the first device. However, Vasisht teaches using UPnP in one of the 
networks [paragraph 0051 line 24]. It would have been obvious for a person having 
ordinary skill in the art to utilize UPnP (various versions include MHS and Home 
network version) in one of the networks. UPnP (both the Home network and MHS 
versions) is desirable because it allows devices to connect seamlessly. 
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5. Claim 36 is rejected under 35 U.S.C. 103(a) as being unpatentable over Rune as applied 
to claims 16-18, 21-25, 28, 32, 34, and 38 above, and further in view of Tung (US 
2006/0136562 Al) (herein after Tung). 

Regarding claim 36, Rune teaches the apparatus according to claim 22 as discussed 
above. However, Rune does not explicitly teach wherein the processor is configured to 
check whether the first device is in sleep mode and, when the first device is in sleep 
mode, the processor is configured to wake up the first device before forwarding the 
packet to the first device. However, Tung in the same field of endeavor teaches a network 
node such as a multimedia server that operates in sleep mode and is only activated when 
receiving a request [see paragraph 0006 and paragraph 0002]. It would have been 
obvious for a person having ordinary skill in the art, at the time of the invention, to check 
whether the nodes in Rune are in sleep mode and when it is in sleep mode wake up the 
node before transmitting a message to the server. This is desirable because it provides for 
power savings. 



Response to Arguments 

6. Applicant's arguments with respect to claims 16-28, 32-34, 36 and 38 have been 
considered but are moot in view of the new ground(s) of rejection. 
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Conclusion 

7. Applicant's amendment necessitated the new ground(s) of rejection presented in this 
Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). 
Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a). 

A shortened statutory period for reply to this final action is set to expire THREE 
MONTHS from the mailing date of this action. In the event a first reply is filed within TWO 
MONTHS of the mailing date of this final action and the advisory action is not mailed until after 
the end of the THREE-MONTH shortened statutoiy period, then the shortened statutory period 
will expire on the date the advisory action is mailed, and any extension fee pursuant to 37 
CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, 
however, will the statutory period for reply expire later than SIX MONTHS from the date of this 
final action. 

Any inquiry concerning this communication or earlier communications from the 
examiner should be directed to SORI AGA whose telephone number is (571)270-1868. The 
examiner can normally be reached on M-F 7:30-4:00. 

If attempts to reach the examiner by telephone are unsuccessful, the examiner's 
supervisor, Ayaz R. Sheikh can be reached on (571)272-3795. The fax phone number for the 
organization where this application or proceeding is assigned is 571-273-8300. 
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Information regarding the status of an application may be obtained from the Patent 
Application Information Retrieval (PAIR) system. Status information for published applications 
may be obtained from either Private PAIR or Public PAIR. Status information for unpublished 
applications is available through Private PAIR only. For more information about the PAIR 
system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR 
system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would 
like assistance from a USPTO Customer Service Representative or access to the automated 
information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000. 



/S. A./ 

Examiner, Art Unit 2476 



/Ayaz R. Sheikh/ 

Supervisory Patent Examiner, Art Unit 
2476 



